Many types of computing applications utilize logging functionality to save data during execution, often to create a record of the application activities. Resulting logs are used to derive information about the execution of the application, information about tasks performed by the application during execution, etc. Logging functionality is used in many different contexts and for many different purposes. For example, logging functionality is often used to de-bug and/or troubleshoot various applications and/or systems. In the context of many business applications, including financial service applications, logging functionality is used to track transactions executed by and/or through the applications. The resulting logs are then used to perform audits, troubleshoot account problems, verify inventory status, demonstrate compliance with applicable regulations, etc.
In many cases, logging functionality is implemented in a multi-thread environment where more than one thread records its activities at a common log location. Multi-thread environments can increase the speed at which application tasks are performed. One example use case involves high frequency securities trading, in which multiple threads are executed with each thread implementing trades determined according to a trading algorithm. The use of multiple threads allows the trades to be implemented faster, thus increasing the efficacy of the trading algorithms. Another example use case for multi-thread and/or multi-application logging is in the context of an operating system where multiple services maintain a common system log.
Logging in a multi-thread and/or multi-application environment requires certain safeguards to prevent different threads or applications from over-writing the others' records. These safeguards are typically implemented as locks or other operating system-level mechanisms. For example, a thread that needs to write to the log must first obtain a lock associated with the log. If the lock is unavailable (e.g., another thread has the lock), the first thread may not write to the log until the lock is released. Although locks can be effective at preventing overwrite, they demonstrate weakness in applications where execution speed is important, such as high frequency securities trading applications. Calls to the operating system to obtain and/or release locks are computationally expensive and time consuming. Also, when a lock required by a thread is unavailable, the thread may not be able to continue its processing until the lock is available, thus slowing overall execution. In some cases where thread execution speed is important, it is known to create logs after execution by analyzing communication messages generated by the threads. For example, high frequency securities trading application threads generate messages requesting the execution of trades. Details of the trades can be extracted by analyzing data packets making up the messages. Analysis of the data packets, however, is also computationally expensive. The packets must be parsed according to their specific transport-layer protocol. Payload data describing the trade or other transaction must then be extracted and properly placed relative to other payload data. Improvements to multi-threaded logging are desired.